SGI MIPSpro Fortran-77 7.2

home *** CD-ROM | disk | FTP | other *** search

/ SGI MIPSpro Fortran-77 7.2 / SGI MIPSpro Fortran-77 7.2.iso / docs6.4 / relnotes / ftn77_fe / ch5.z / ch5

Wrap

Text File | 1997-09-04 | 31KB | 660 lines

- 1 - 7.2 Fortran 77 Front-End Release Notes - 2 - DDDDooooccccuuuummmmeeeennnntttt NNNNuuuummmmbbbbeeeerrrr 000000007777----1111666655559999----000011110000 5. _K_n_o_w_n__P_r_o_b_l_e_m_s__a_n_d__W_o_r_k_a_r_o_u_n_d_s This chapter describes the known problems with the current release of the Fortran product and how to work around them. Some of the descriptions are followed by a Silicon Graphics, Inc., bug report number in the form (Bug ID xxxxx). 5.1 _K_n_o_w_n__P_r_o_b_l_e_m_s__(_L_i_c_e_n_s_i_n_g_) +o The MIPSpro F77 compiler will abort if the license file directory (/var/flexlm) contains a cycle formed by symbolic links. For example: %ls -l /var/flexlm lrwxr-xr-x 1 root sys 1 Mar 13 1996 license -> . -rw-r--r-- 1 root sys 1162 Aug 20 17:09 license.dat %f77 foo.f Bus error (core dumped) The solution is to remove the symbolic link that forms the cycle. +o Cryptic warning message from licensing. The first line of a warning message that occurs when a license file exists under /var/flexlm but does not contain the compiler license can be misleading. For completeness the following example illustrates the entire output when a license file exists, but a license is not installed: - 3 - %f77 foo.f No such feature exists (-5,116) The MIPSpro Fortran 77 Compiler (license FEATURE string = f77) requires a license password. For license installation and trouble shooting information visit the web page: http://www.sgi.com/Support/Licensing/install_docs.html To obtain a Permanent license (proof of purchase required) or an Evaluation license please visit our license request web page: http://www.sgi.com/Products/license.html or send a blank email message to: license@sgi.com In North America, Silicon Graphics' customers may request Permanent licenses by sending a facsimile to: (650) 932-0537 or by calling our technical support hotline 1-800-800-4SGI If you are Outside of North America or you are not a Silicon Graphics support customer then contact your local support provider. 5.2 _K_n_o_w_n__P_r_o_b_l_e_m_s__i_n__M_I_P_S_p_r_o__F_o_r_t_r_a_n__7_7 The problems described in this section are known to exist in MIPSpro Fortran 77 in both 32-bit and 64-bit compilation modes. References to the 64-bit compiler implicitly refer to ----nnnn33332222 compilations as well. +o SSSSyyyymmmmbbbboooollll ccccllllaaaasssshhhh wwwwiiiitttthhhh _llll_iiii_bbbb_ffff_tttt_nnnn_...._ssss_oooo ((((BBBBuuuugggg IIIIDDDD 111155554444888844445555)))) Some programs which used to link correctly with previous releases get an _l_d error because of conflicting symbol definitions between their symbols and those of _l_i_b_f_t_n._s_o. Work around this by compiling with the - 4 - -_n_o_n__s_h_a_r_e_d option. +o CCCCoooommmmppppiiiilllliiiinnnngggg oooolllldddd FFFFoooorrrrttttrrrraaaannnn ccccooooddddeeee Fortran, by default, allocates local variables on the stack for faster execution speed. These local automatic variables are uninitialized, as opposed to being initialized to zeros, which occurs using the static allocation of older Fortran systems. Also, the value of an automatic variable is not retained between successive calls to a subroutine as for a static variable. Therefore, if you have an old program, especially one ported from the VAX, that behaves strangely, recompile it with ----ssssttttaaaattttiiiicccc and check the results. If using ----ssssttttaaaattttiiiicccc works correctly, the problem is caused by automatic allocation of undeclared static variables. If execution speed is not an issue, the program can be compiled with ----ssssttttaaaattttiiiicccc without having to be modified. Otherwise, you need to track down all variables that expect an initial value (either a zero value when starting a program or the value from the previous subroutine invocation in a subroutine call) and declare those variables as static using the STATIC statement. Using the ----LLLLIIIISSSSTTTT option can help in tracking these static variables. Running these old programs without the ----ssssttttaaaattttiiiicccc compilation option sometimes results in very slow execution speed because the supposedly static values are undefined and take a lot more time to converge. So the first thing to try when you have an unusual performance problem when porting a program to a Silicon Graphics platform is to add the ----ssssttttaaaattttiiiicccc option when compiling. +o VVVVaaaarrrriiiiaaaabbbblllleeee ffffoooorrrrmmmmaaaatttt iiiinnnn aaaa cccchhhhaaaarrrraaaacccctttteeeerrrr ssssttttrrrriiiinnnngggg ((((BBBBuuuugggg IIIIDDDD 8888777777774444)))) Variable format is only recognized inside a FORMAT statement. If it is used within a character string, it will give a runtime error. Work around this bug by making an explicit FORMAT statement when variable format is desired. +o RRRRuuuunnnnttttiiiimmmmeeee IIII////OOOO eeeerrrrrrrroooorrrr mmmmeeeessssssssaaaaggggeeeessss ((((BBBBuuuugggg IIIIDDDD 9999222288884444)))) All Fortran I/O error messages are documented - 5 - in _p_e_r_r_o_r(3F) and all IRIX system error messages are documented in _i_n_t_r_o(2). Some of these numbers overlapped and sometimes the wrong error messages are printed for a given error number. When the error message does not make sense, it's best to check both man pages to see which one applies. 5.3 _K_n_o_w_n__P_r_o_b_l_e_m_s__i_n__M_I_P_S_p_r_o__6_4_-_B_i_t__F_o_r_t_r_a_n__7_7 +o PPPPrrrroooobbbblllleeeemmmmssss wwwwiiiitttthhhh MMMMPPPP pppprrrroooocccceeeesssssssseeeessss lllloooocccckkkkeeeedddd oooonnnnttttoooo aaaa ccccppppuuuu The Power Challenge machines have the special hardware device /dev/ccsync to help reduce the overhead of an MP job, and this device is used by default. However, due to necessary compromises in the design, if an MP job uses this device, the mp library will lock the master process onto a cpu via the equivalent of the sysmp(MP_MUSTRUN) system call. There are some unfortunate side effects of this: you may not execute the sysmp(MP_RUNANYWHERE) command for the master process; the mp synchronization will fail if you do. Some users lock the master and each of the slave processes onto separate cpus. This can fail in the same way as above if the master process gets assigned to a different cpu. Process locking is an inherited attribute; this means that if your MP program forks or sprocs other child processes, they will be locked onto the same cpu as the master, which can seriously degrade performance. This can be worked around by having the newly created child process execute sysmp(MP_RUNANYWHERE). If for some reason you must do your own process locking, and/or cannot get the newly created children to execute sysmp(MP_RUNANYWHERE), the problem can be avoided by setting the environment variable _MP_DONT_USE_CCSYNC, which will prevent MP jobs run by that shell from using /dev/ccsync. +o TTTToooooooo mmmmaaaannnnyyyy ccccaaaallllllllssss ttttoooo mmmmpppp____ddddeeeessssttttrrrrooooyyyy Due to a problem in libmp.a, if a process creates and destroys MP processes (via mp_destroy) more than about 35 times in a single run, an internal table will overflow and you will get the message: "Error: MP lib could not register __mp_cleanup function via __ateachexit". Note that MP process - 6 - destruction must be done deliberately; the default behavior is to create the processes once, and to keep them around until the job terminates. There is no viable workaround for this problem (other than calling mp_destroy less often). +o LLLLooooggggiiiiccccaaaallll vvvvaaaarrrriiiiaaaabbbblllleeeessss hhhhoooolllldddd iiiinnnntttteeeeggggeeeerrrr vvvvaaaalllluuuueeeessss In the 32-bit compiler, when LOGICAL*2, LOGICAL*4, and LOGICAL*8 variables are assigned integer values (an extension to the Fortran 77 standard), the values are converted to .TRUE. or .FALSE. (one and zero, respectively) before being assigned to the variables. In the 64-bit compiler, the LOGICAL variable is assigned the bit pattern corresponding to the integer expression. +o IIIInnnnlllliiiinnnneeee ooooppppttttiiiioooonnnn ////NNNNOOOOFFFF77777777 iiiissss nnnnooootttt ssssuuuuppppppppoooorrrrtttteeeedddd ((((BBBBuuuugggg IIIIDDDD 111188888888555544449999)))) This option is ignored by the 64-bit compiler. +o AAAAddddjjjjuuuussssttttaaaabbbblllleeee aaaarrrrrrrraaaayyyy ddddiiiimmmmeeeennnnssssiiiioooonnnnssss ccccaaaannnn''''tttt bbbbeeee aaaarrrrrrrraaaayyyy vvvvaaaalllluuuueeeessss ((((BBBBuuuugggg IIIIDDDD 222200001111666655554444)))) Although this has always been documented as illegal in SGI Fortran, the 32-bit compiler accepts this syntax, whereas the 64-bit compiler emits a compile-time error. +o TTTThhhheeee ----XXXXllllooooccccaaaallllddddaaaattttaaaa ooooppppttttiiiioooonnnn hhhhaaaassss cccchhhhaaaannnnggggeeeedddd ssssyyyynnnnttttaaaaxxxx The 64-bit loader uses a different syntax for the option to make each thread in an MP program have its own copy of a common block. In the 32-bit loader, the option is ----XXXXllllooooccccaaaallllddddaaaattttaaaa ccccoooommmmmmmmoooonnnn____nnnnaaaammmmeeee____ while the 64-bit loader uses ----WWWWllll,,,,----XXXXllllooooccccaaaallll,,,,ccccoooommmmmmmmoooonnnn____nnnnaaaammmmeeee____. Also, the 32-bit loader allows list of ccccoooommmmmmmmoooonnnn____nnnnaaaammmmeeees with the one ----XXXXllllooooccccaaaallllddddaaaattttaaaa option, while the 64-bit loader allows only one name per ----XXXXllllooooccccaaaallll option (but does allow multiple ----XXXXllllooooccccaaaallll options). +o NNNNoooo wwwwaaaarrrrnnnniiiinnnnggggssss ffffoooorrrr mmmmiiiissssaaaalllliiiiggggnnnneeeedddd ccccoooommmmmmmmoooonnnn bbbblllloooocccckkkkssss The 32-bit compiler warns for misaligned COMMON blocks, whereas the 64-bit compiler does not. +o SSSSttttrrrriiiicccctttteeeerrrr cccchhhheeeecccckkkkiiiinnnngggg oooonnnn GGGGOOOOTTTTOOOO''''ssss The MIPSpro manuals document that GOTO is only valid when the branch is to an - 7 - executable statement. The 64-bit compiler is stricter about enforcing this rule than the 32-bit compiler. +o 222255556666----cccchhhhaaaarrrraaaacccctttteeeerrrr lllliiiimmmmiiiitttt oooonnnn lllliiiinnnneeee lllleeeennnnggggtttthhhh The 32-bit compiler has no limit on the length of a source line, whereas the 64-bit compiler limits a line to 256 characters. Continuation lines may be used for source lines longer than 256 characters. +o 99999999 mmmmaaaaxxxxiiiimmmmuuuummmm ccccoooonnnnttttiiiinnnnuuuuaaaattttiiiioooonnnn lllliiiinnnneeeessss The compiler allows the maximum number of continuation lines (99 by default) to be increased by using -Wf,-NC<number>. +o ----mmmmpppp____kkkkeeeeeeeepppp nnnnooootttt rrrreeeeccccooooggggnnnniiiizzzzeeeedddd This option is needed for debugging parallel applications when the 32-bit compilers are used, but is unnecessary with the 64-bit compilers, as proper debugging info is generated when the ----gggg compiler option is used. +o ----wwww66666666 iiiissss nnnnooootttt iiiimmmmpppplllleeeemmmmeeeennnntttteeeedddd The ----wwww66666666 option is not implemented in this release. +o ----66666666 iiiissss nnnnooootttt iiiimmmmpppplllleeeemmmmeeeennnntttteeeedddd The ----66666666 option is not implemented in this release. +o ----uuuusssseeeeffffppppiiiiddddxxxx iiiissss nnnnooootttt iiiimmmmpppplllleeeemmmmeeeennnntttteeeedddd The ----uuuusssseeeeffffppppiiiiddddxxxx option is not implemented in this release. +o ----UUUU iiiissss nnnnooootttt iiiimmmmpppplllleeeemmmmeeeennnntttteeeedddd The ----UUUU option is not implemented in this release. +o NNNNaaaammmmeeeelllliiiisssstttt ssssyyyymmmmbbbboooollllssss ssssiiiilllleeeennnnttttllllyyyy ttttrrrruuuunnnnccccaaaatttteeeedddd ((((BBBBuuuugggg IIIIDDDD 333377778888888899991111,,,, 333377778888999900008888)))) In the 64-bit compiler, symbols are recognized for their full length in all contexts other than namelists where they are silently truncated if they are longer than 31 characters. +o CCCCoooommmmppppiiiilllleeee----TTTTiiiimmmmeeee eeeerrrrrrrroooorrrrssss ffffoooorrrr oooovvvveeeerrrrllllaaaappppppppiiiinnnngggg iiiinnnniiiittttiiiiaaaalllliiiizzzzaaaattttiiiioooonnnnssss uuuussssiiiinnnngggg DDDDAAAATTTTAAAA ssssttttaaaatttteeeemmmmeeeennnnttttssss ((((BBBBuuuugggg IIIIDDDD 333300005555888888881111)))) - 8 - The 64-bit compiler can produce errors during compilation of programs that include overlapping initializations using DATA statements. 5.4 _K_n_o_w_n _P_r_o_b_l_e_m_s _i_n _M_I_P_S_p_r_o _6_4-_B_i_t _a_n_d _N_3_2 _F_o_r_t_r_a_n _7_7 +o BBBBuuuussss EEEErrrrrrrroooorrrr wwwwhhhheeeennnn ccccoooommmmppppiiiilllliiiinnnngggg wwwwiiiitttthhhh ----IIIIPPPPAAAA ((((BBBBuuuugggg IIIIDDDD 555522221111111133339999)))) Compiling a program that contains an initialization of an element of a COMMON block will abort with a bus error in the compiler if the program links with a shared object that contains a declaration of the same COMMON block and the compilation is done with the ----IIIIPPPPAAAA option. 5.5 _K_n_o_w_n__P_r_o_b_l_e_m_s__i_n__M_I_P_S_p_r_o__3_2_-_B_i_t__F_o_r_t_r_a_n__7_7 +o EEEExxxxeeeeccccuuuuttttaaaabbbblllleeee ssssttttaaaatttteeeemmmmeeeennnnttttssss iiiinnnn iiiinnnncccclllluuuuddddeeee ffffiiiilllleeeessss ((((BBBBuuuugggg IIIIDDDD 5555555599993333)))) Executable statements are not allowed inside include files because of a symbol table requirement that all executable statements of the same program unit, or, at least, the first and the last executable statements, come from the same source file. When executable statements are used inside include files, the compiler sometimes gives an internal _l_i_b_m_l_d error when compiled with the ----gggg option. Please avoid using executable statements inside include files. +o CCCCoooonnnnccccaaaatttteeeennnnaaaattttiiiioooonnnn iiiinnnn WWWWRRRRIIIITTTTEEEE ssssttttaaaatttteeeemmmmeeeennnntttt ((((BBBBuuuugggg IIIIDDDD 9999444488887777)))) Concatenation of character strings with variable lengths is not allowed in WRITE statements, although this can now be done in subroutine calls as an extension to the ANSI standard. The workaround is to use comma to replace the concatenation operator since all Fortran output items are automatically concatenated as a matter of fact so the concatenation operation which puts the concatenated result into a temporary buffer is unnecessary, slows down the execution, and causes the program to be less portable. - 9 - +o _cccc_pppp_pppp ddddooooeeeessss nnnnooootttt rrrreeeeccccooooggggnnnniiiizzzzeeee FFFFoooorrrrttttrrrraaaannnn ccccoooonnnnttttiiiinnnnuuuuaaaattttiiiioooonnnn lllliiiinnnneeeessss _c_p_p does not recognize Fortran continuation lines, so it can mistakenly think that a word is outside of a character string when that word is continued across lines. If that word is defined with the ----DDDD option or by #define to be something else, _c_p_p can replace it with another value, resulting in the wrong character string value. To work around this problem, either compile with the ----nnnnooooccccpppppppp option or break the word pattern into two lines so that _c_p_p cannot recognize it. +o ----bbbbaaaacccckkkkssssllllaaaasssshhhh ddddooooeeeessss nnnnooootttt wwwwoooorrrrkkkk wwwwiiiitttthhhh _cccc_pppp_pppp Although the ----bbbbaaaacccckkkkssssllllaaaasssshhhh option causes _f_c_o_m to treat the backslash character as normal character, _c_p_p still treats it as special escape sequence and causes unexpected behavior. Use ----nnnnooooccccpppppppp as a workaround. +o UUUUssssiiiinnnngggg uuuunnnnddddeeeeccccllllaaaarrrreeeedddd aaaarrrrrrrraaaayyyyssss iiiissss mmmmiiiissssiiiinnnntttteeeerrrrpppprrrreeeetttteeeedddd aaaassss aaaa ssssttttaaaatttteeeemmmmeeeennnntttt ffffuuuunnnnccccttttiiiioooonnnn ((((BBBBuuuugggg IIIIDDDD 8888444499991111)))) Referencing an array element on the left-hand side of an assignment without declaring the dimension for the array can cause the assignment statement to be misinterpreted as a statement function. +o MMMMuuuullllttttiiiipppplllleeee ddddeeeeffffiiiinnnniiiittttiiiioooonnnnssss ooooffff ccccoooommmmmmmmoooonnnn bbbblllloooocccckkkkssss ((((BBBBuuuugggg IIIIDDDD 11111111666622229999)))) When a common block is defined several times in different files by using DATA statements to initialize one or more of the common block elements, the linker produces an error message regarding multiple definitions of symbols. Solve this problem by moving all initialization of the same common block to one subroutine or block data. +o VVVVeeeerrrryyyy llllaaaarrrrggggeeee aaaarrrrrrrraaaayyyyssss ccccaaaauuuusssseeee sssseeeeggggmmmmeeeennnnttttaaaattttiiiioooonnnn ffffaaaauuuulllltttt ((((BBBBuuuugggg IIIIDDDD 11111111999999994444)))) When large arrays are declared inside a subroutine, the program can get a segmentation fault at execution time. When this happens, check for the sizes of the declared arrays and reduce them if possible. +o LLLLiiiinnnneeee nnnnuuuummmmbbbbeeeerrrr ffffoooorrrr ddddeeeeccccllllaaaarrrraaaattttiiiioooonnnn eeeerrrrrrrroooorrrr mmmmeeeessssssssaaaaggggeeeessss ((((BBBBuuuugggg IIIIDDDD 11112222999933336666)))) - 10 - Since many Fortran declarations are interrelated, the actual characteristics of a variable is not known until all declarations have been done, that is at the first executable statement. Therefore, the error messages indicate the first executable statement when the actual error is due to the wrong combination of the declarations. This problem usually effects variables declared in COMMON blocks and EQUIVALENCE statements.